Make Sel an opaque struct like Ivar, Method, Class, Protocol and Object
#105
Conversation
The discrepancy between usage of `Class`/`Object`/... and `Sel` annoyed me, the others were used behind pointers / references, while `Sel` was consumed directly. This changes the definition of `Sel` to be like the other types (so it has to be used as `&Sel`), and also opens up for the possiblity of non-static selectors (if that ever becomes a thing). This is a breaking change, but fortunately most cases where `Sel` is used in user code (e.g. `add_method`) the error is caught at compile-time, with recommendations on how to fix it.
|
Selectors in objective-c are treated like they have copy semantics. Why does the discrepancy here annoy you? Is there a benefit to having a lifetime on selectors? I don't believe there will be a need for non-static selectors. If anything, perhaps making Class/Method/etc references was the mistake, because those lifetimes are barely ever useful in practice. (idk if anything ever actually gets unregistered from the objc runtime) |
|
Mostly it just confused me since all the other types worked the other way. But I think it actually would make the workings of But no, I don't think you can actually get a non-static selector. Classes however can be destroyed with |
The discrepancy between usage of
Class/Object/... andSelannoyed me, the others were used behind pointers / references, whileSelwas consumed directly.This changes the definition of
Selto be like the other types (so it has to be used as&Sel), and also opens up for the possiblity of non-static selectors (if that ever becomes a thing).This is a breaking change, but fortunately most cases where
Selis used in user code (e.g.add_method) the error is caught at compile-time, with recommendations on how to fix it.